home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 13042 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: po.CWRU.Edu!mab22
  2. From: mab22@po.CWRU.Edu (Michael A. Balfour)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Variant Records in C ... Is there a way ?
  5. Date: 4 Apr 1996 02:52:35 GMT
  6. Organization: Case Western Reserve University, Cleveland, OH (USA)
  7. Message-ID: <4jvdhj$mag@madeline.INS.CWRU.Edu>
  8. References: <Pine.OSF.3.91.960319170252.9783B-100000@alfa.ist.utl.pt> <315006F8.639@cmt.lpr.mail.carel.fi> <4iumf8$604@madeline.INS.CWRU.Edu> <danpop.827534657@rscernix> <4jcrbm$g5p@madeline.INS.CWRU.Edu> <828145096snz@genesis.demon.co.uk>
  9. Reply-To: mab22@po.CWRU.Edu (Michael A. Balfour)
  10. NNTP-Posting-Host: kanga.ins.cwru.edu
  11.  
  12.  
  13. In a previous article, fred@genesis.demon.co.uk (Lawrence Kirby) says:
  14.  
  15. >In article <4jcrbm$g5p@madeline.INS.CWRU.Edu>
  16. >           mab22@po.CWRU.Edu "Michael A. Balfour" writes:
  17. >
  18. >>
  19. >>In a previous article, danpop@mail.cern.ch (Dan Pop) says:
  20. >>
  21. >>>In <4iumf8$604@madeline.INS.CWRU.Edu> mab22@po.CWRU.Edu (Michael A. Balfour)
  22. >> writes:
  23. >>>
  24. >>>>*However*, if you feel like it, you can still do it yourself with some
  25. >>>>clever mallocs and overlaying structures.  Not exactly elegant, but you
  26. >>>>can make it pretty memory-efficient.
  27. >>>
  28. >>>Not exactly blessed by the C standard, either :-)
  29. >>>
  30. >>
  31. >>Maybe not blessed, but it's certainly not condemned.
  32. >
  33. >You'll almost certainly invoke undefined behaviour as far as the language
  34. >is concerned. So it is in the same category as void main() or i = i++,
  35. >i.e. condemned to be non-portable.
  36. >
  37.  
  38. You're willing to make a broad generalization, but you aren't backing it
  39. up with any substance.  *Why* will it almost certainly invoke undefined
  40. behavior?  You're allowed to treat memory like a series of bytes or
  41. chars, and that's *extremely* well-defined.  Of course, treating it
  42. correctly is always up to the programmer, but there's no reason why a
  43. programmer will "almost certainly" do it wrong.
  44.  
  45. In fact, it sounds like you agree with me a little later in your post:
  46.  
  47. >The language does give license to access any object through character
  48. >lvalues. It has been suggested that future revisions of the standard will
  49. >clarify the issue so that, say copying an object as an array of unsigned char
  50. >works (as long as you end up with suitable alignment). Anyway this is a better
  51. >approach than using unions.
  52.  
  53. See?
  54.  
  55. >
  56. >That doesn't mean that ANSI C will guarantee that your code does what
  57. >you expect.
  58. >
  59.  
  60. Of course not.  In fact, relying on variables names to understand code
  61. doesn't always give you what you expect either.  For that matter, if
  62. ANSI C *did* guarantee that my code does what I expect, I'd sell all my
  63. debugging tools today.  :)  All I was trying to say was that this (i.e.
  64. using memory as a series of bytes) was one solution to the problem if
  65. implemented correctly.  And that unions were not a solution, because the
  66. original poster specified that they were trying not to use the extra
  67. filler-byte memory that unions require.
  68.  
  69. Mike Balfour
  70.  
  71. -- 
  72. ----------------------------------+--------------------------------
  73. Mike Balfour, Partner             | BS/MS Graduate - ECMP
  74. Overload Engineering              | Case Western Reserve University
  75. "New Ideas for a Brighter Future" | Cleveland, OH
  76.